When a conflicting hunk sits at end-of-file without a trailing newline, merge/merge_bytes
glue the next conflict marker onto the content line, producing unparseable output:

    base:   "This is line 1.\nThis is line 2."
    ours:   "This is line 1.\nThis is line 2 changed."
    theirs: "This is line 1.\nThis is line 2 also changed."

Actual:

    This is line 1.
    <<<<<<< ours
    This is line 2 changed.||||||| original
    This is line 2.=======
    This is line 2 also changed.>>>>>>> theirs

Expected (matches git merge-file --diff3 on identical inputs):

    This is line 1.
    <<<<<<< ours
    This is line 2 changed.
    ||||||| original
    This is line 2.
    =======
    This is line 2 also changed.
    >>>>>>> theirs

add_conflict_marker/add_conflict_marker_bytes now prefix a newline when the output
doesn't already end with one. Only reachable for file-final hunks, so all existing merge
output is unchanged — the full suite passes untouched. One new test covers both the str
and bytes paths via assert_merge!.